1. Field of the Invention
The present invention relates to a meta-data registration scheme to be utilized in a data server device. In the following description, a word “meta-data” stands for any data on a registered data (or data to be registered) which can be utilized in handling or managing the registered data.
2. Description of the Background Art
In a system for providing information to users through information terminals and information processing by computers, a data server device has been used as a device for registering and storing data, from which a specified data can be retrieved or data satisfying a desired condition can be searched and retrieved. The data server device can be implemented in a form of a file system or a database management system which is a part of an operating system of a computer, or a Web server, file server or database server with respect to which data can be entered or retrieved through a network.
A Web server which is one variant of the data server device manages various data on a name space having tree-like hierarchical structure as shown in FIG. 1. In this example, “/proj/doc/fig/image1.gif” and “/proj/doc/fig/image2.gif” are image data in GIF format, “/proj/doc/spec.doc” is a document produced by a word processor (MS-WORD), “/proj/src/program.c” is a source code of a program written in the C language, and “/sample/index.html” is a document file written in HTML. Nodes that classify data such as nodes specified by “/proj” or “/proj/doc/fig” are generally referred to as directories. In each directory, arbitrary many data or directories can be included. A directory “/” that is at a top level in FIG. 1 will be referred to as a root directory.
Data managed by the Web server can be accessed by the HTTP protocol through a network. The HTTP protocol is disclosed in “Hypertext Transfer Protocol—HTTP/1.0” (RFC 1945) and “Hypertext.Transfer Protocol—HTTP/1.1” (RFC 2068). When some client wishes to obtain data of “/proj/doc/fig/image1.gif”, for instance, this client sends a GET request having a header in a format of “GET /proj/doc/fig/image1.gif HTTP/1.1” to this Web server. Upon receiving this request, the Web server returns the requested data.
In order to register data on the Web server, a PUT request of the same HTTP protocol is used. When some client wishes to register a new image data in the GIF format under the name of “/proj/doc/fig/image3.gif”, for instance, this client sends a PUT request having a header in a format of “PUT /proj/doc/fig/image3.gif HTTP/1.1” to this Web server, while containing the image data to be registered in a body of this PUT request. Upon receiving this request, the Web server stores the received image data under the specified name.
In the HTTP protocol, a type of data to be exchanged by GET or PUT in terms of a MIME type. For instance, a type of data to be transferred is specified by a header in a form of “Content-type: image/gif”.
A UNIX file system which is another example of the data server device manages various data (called files in the case of the file system) on a name space having a tree-like hierarchical structure as shown in FIG. 2. In the example of FIG. 2, “proc.c” and “sys.h” are referred to as files, while “src” and “include” are referred to as directories. At a time of accessing a file in the file system, a file name of a file to be accessed is specified by a file name having a hierarchical structure such as “/src/kernel/proc.c”.
It is well known that data managed by the data server device can be handled more conveniently by attaching meta-data to each data. There are various examples of the meta-data including creation date and location, a creator, an access control information, an update log, a data source (information indicating where this data comes from), a channel, an EPG (electronic program guide), a thumb nail in the case of image data, an icon to be displayed by GUI, a position to be displayed on a display, an application that created that data, an application for browsing that data, a MIME type of data, a size of data, and keywords to be used in the retrieval.
Meta-data is also referred to as property or attribute in some contexts.
When data are managed by attaching meta-data, it becomes possible not only access data by specifying its name, but also retrieve the data by specifying a value of its meta-data, or manage information necessary for applications in relation to the data.
A scheme for registering meta-data in the Web server is disclosed as a part of the specification called WebDAV in “HTTP Extensions for Distributed Authoring—WEBDAV” (Internet Draft: draft-ietf-webdav-protocol-10). In the WebDAV, it is possible to attach meta-data called property to data managed by the Web server.
The Web server compatible with WebDAV manages data as shown in FIG. 3. It is basically the same as the Web server shown in FIG. 1, but unlike the usual Web server, it manages data and meta-data (property) in relation to each other. The property is maintained by a pair of a name and a value. In the example of FIG. 3, data specified by “/doc/fig/image1.gif” has three properties of “author”, “date” and “access”. The “author” property has a creator of the data as its value, which is “T. Sato” in this case. The “date” property indicates the date on which the data was created and the “access” property indicates an access right information in this example.
In the WebDAV, a directly is referred to as a collection. In FIG. 3, intermediate nodes of the tree specified by “/” or “/doc/fig” are collections. In the specification of the WebDAV, it is possible to attache a meta-data to the collection as well. In the following description, this collection will also be referred to as a directory.
In the WebDAV, new request methods are added by extending the HTTP protocol in order to access the property. More specifically, a PROPFIND method is provided in order to extract a value of the property, and a PROPPATCH method is provided in order to set up or delete a value of the property. By issuing a request using these methods, it becomes possible to access the property. The bodies of PROPFIND or PROPPATCH requests and replies are required to be described using XML.
A scheme for retrieving data managed by attaching the property according to the specification of the WebDAV is called a DASL, which is disclosed in “DAV Searching & Locating” (Internet Draft: draft-reddy-dasl-protocol-04. txt). The DASL adds a SEARCH method for the retrieval by expanding the HTTP protocol, such that when a SEARCH request containing a retrieval condition described by XML in its body is sent, a corresponding retrieval result written in the same XML will be returned. In the retrieval condition, a value of a property of a specific name can be specified with respect to a certain property or a combination of a plurality of properties.
An exemplary case of registering meta-data in the UNIX type file system includes a Be file system disclosed in Dominic Giampaolo: “Practical File System Design with the Be File System”, Morgan Kaufmann Publishers, Inc., ISBN 1-55860-497-9. The Be file system manages files in the name space having a tree-like hierarchical structure similar to the UNIX, where meta-data called attribute can be attached to each file. The attribute is given by a pair of a name and a value, where the name is given by a character string, and the value is given by data such as a character string, integer, real number, binary number, etc.
Similarly as in the DASL, files can be retrieved using an attribute value or a combination of attribute values in the Be file system.
As described, in the data server device capable of managing meta-data, it is possible to manage various information as meta-data in relation to the data. In addition, it becomes possible to realize sophisticated accesses based on the retrieval using various information as keys, rather than a simple access using a name of data or file. Furthermore, the construction of an application program can be also made easier as the application manages information related to data as meta-data in relation to the data.
The data server device for managing meta-data in relation to data has various advantageous features as described above, but the full advantages of these features cannot be taken unless meta-data are actually attached to individual data. However, attaching meta-data to individual data requires enormously tedious tasks.
There are meta-data such as creation date and size of a file which can be attached automatically at a time of registering data. However, such meta-data are limited only to the generic meta-data that do not depend on data type and the like. If tasks to attach meta-data can be made automatic somehow, even to some extent, for the other kinds of meta-data, it is possible to expect that the user will be relieved from tedious tasks.
Also, at a time of attaching meta-data, if different names are used for the meta-data having the same meaning depending on persons who attach them or times at which they are attached, or if the meta-data are attached to the data of the same type under arbitrarily different names by different applications, it becomes impossible to realize the effective retrieval later on. Consequently, there has been a demand for a way to attach meta-data systematically to some extent.